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COMMON CONNECTOR FRAMEWORK 
A BSTRA CI 

An object oriented framework for communication between an application component running in an 
infrastructure and a backend system. The framework includes a connector protocol definition for 
a implementation by a connector component. The connector component enables and constrains 
commimication between the application component and the backend system. The framework 
5 provides client view interface definitions for communication between the application component and 

the coimector component, and infrastructure view interface definitions for communication between 
the infirastructure and the connector component. 
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COMMON CONNECTOR FRAMEWORK 



The present invention is directed to an improvement in computing systems and in particular to a 
framework providing common connections between computer systems and computer software. 



BACKGROUND OF THE INVENTION 

A large number of software products are designed to be used to permit the connection different 
computer systems running on various hardware platforms and under different software 
configurations. This type of connecting software is referred to as "middleware", and is used to 
provide clients (application programs or their components) with an access to different types of 
systems, such as transaction servers or database systems (referred to as "backend systems"). 

Middleware is often provided as a library which is specific to a particular programming language 
and operating system. The middleware library provides to client programs a well defined set of APIs 
used to access the middleware and the backend system which the client is seeking to communicate 
with. 

There are several problems with this middleware approach. For the middleware implementors, the 
main problem is the variety of the backend computer systems that middleware has to use. For each 
such computer system, often very different in its support and services, the middleware has to provide 
consistent behaviour e.g. error reporting mechanism, often having to implement its services multiple 
times. 



The main problem for the clients is the number of different APIs that even a simple client may be 
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required to support. Each middleware product has its own requirements, and a client that is designed 
to use several backend systems will typically be required to communicate using more than one piece 
of middleware. The result is that the client program or system has to support an ever growing 
number of specific APIs. The more versatile and powerful the client becomes, the more complexity 
5 is associated with the client’s access to backend systems and the resulting expanded use of 
middleware systems. Even more severe problems may potentially occur when the client constitutes 
a part of a tool or a framework. In that case maintaining flexibility in the tool or framework comes 
at the cost of increasing the client, and therefore tool or framework, complexity. 

It is therefore desirable to have a set of interfaces, or protocols, which will define how client 
1 0 programs access backend systems. Such a set of interfaces, or protocols, will permit clients to access 

backend systems using the same set of APIs independent of die concrete implementation of those 
APIs. It is desirable to have such inter&ces or protocols implemented as a framework, which is able 
to utilize object oriented programming and design concepts to provide a formal definition of the set 
of interfaces so as to permit middleware to be replaced with a tool which will permit a uniform 
1 S approach to accessing backend systems. 



SUMMARY OF THE INVENTION 

According to one aspect of the present invention, there is provided an improved computer system 
for client to backend system communication. 

20 According to another aspect of the present invention, there is provided an object oriented framework 

for communication between an application component running in an infrastructure and a backend 
system, comprising a connector protocol definition for a implementation by a connector component 
for communication between the application component and the backend system, the framework 
further comprising a client view protocol definition for communication between the application 
25 component and the connector component, and an infrastructure view protocol definition for 

2 
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communication between the infrastructure and the connector component. 

According to another aspect of the present invention, there is provided the above object oriented 
framework in which the client view protocol definition comprises a connection specification protocol 
definition to define communication of backend system connection properties to the connector 
component, an interaction specification protocol definition to define communication of properties 
associated with application component requests of backend system, a communication specification 
protocol definition to define connection, disconnection and execution of communication functions 
for communication between the application component and the backend system. 

According to another aspect of the present invention, there is provided the above object oriented 
framework in which the infrastructure view protocol definition comprises a set of managed 
connection protocol definitions to define the creation and management of connections between the 
application component and the backend system, wherein the set of managed connection protocol 
definitions comprises a first subset of managed connection protocol definitions for implementation 
in the connector component and a second subset of managed connection protocol definitions for 
implementation in the infiastructure, a set of resource coordination protocol definitions to define 
coordination of resources relating to connections between the application component and the 
backend system, wherein the set of resource coordination protocol definitions comprises a first 
subset of resource coordination protocol definitions for implementation in the connector component 
and a second subset of resource coordination protocol definitions for implementation in the 
infrastructure, an identifier protocol definition for implementation by the infrastructure to provide 
connector component access to a unique identifier, a logon information protocol definition for 
implementation by the infrastructure to provide connector component access to security items in the 
infrastructure, a compxment definition for logon information for definition of security items required 
for connector component communication between the application component and the backend 
system, a RAS protocol defimtion for implementation by the infiustructure to provide connector 
access to error and trace logging. 



3 
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According to another aspect of the present invention, there is provided the above object oriented 
framework wherein the application component runs on a thread in an infrastructure provi ding 
infrastructure services, the object oriented framework further comprising means for the infrastructure 
to provide infrastructure services to the connector component by associating a runtime context of 
5 the infrastructure services with the thread of the application component 

According to another aspect of the present invention, there is provided the above object oriented 
framework in which the first subset of managed connection protocol definitions comprises a protocol 
definition for the creation of a connection, and a protocol definition for providing a connection 
manager component with control over a managed connection, and in which the second subset of 
1 0 managed connection protocol definitions comprises a protocol definition for reserving and releasing 

managed connections. 

According to another aspect of the present invention, there is provided the above object oriented 
framework in which the first subset of resource coordination protocol definitions comprises a 
protocol definition for creating a view of a connection resource for use by a resource coordinator, 
15 and in which the second subset of resource coordination protocol definitions comprises a protocol 
definition for registration of resources by a resource coordinator. 

According to another aspect of the present invention, there is provided the above object oriented 
frameworks in which the fimnework is implemented in the Java program ming languages and in 
which the protocol definitions are interfaces in the Java programming language. 

20 According to another aspect of the present invention, there is provided the above object oriented 
fiamework in which the application component runs on a thread in a Java infirastructure, the object 
oriented framework further comprising means for the infiastructure to provide infiastructure services 
to the connector component by associating a Java runtime context with the thread of the application 
component. 

25 According to another aspect of the present invention, there is provided a computer system 

4 
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comprising a set of tools for use to create a communication between a first computer system 
component and a second computer system component, the tools constraining the communication to 
occur using a predefined protocol, the set of tools comprising a connector tool for a implementation 
by a connector for communication between the first computer system component and the second 
computer system component, the connector tool comprising a client view tool for defining 
communication between the application component and the connector component, and an 
infrastructure view tool for defining communication between the infrastructure and the connector 
component 

Advantages of the present invention include the provision of a ffameworic to define the interaction 
between the client and the backend such that the same framework may be implemented for different 
infrastructures and different backend systems. The need for clients to utilize different APIs, and for 
infirastructures to support different middleware systems, is therefore reduced. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The preferred embodiment of the invention is shown in the drawings, wiierein: 

Figure 1 is a block diagram showing the architecture of the framework of the preferred 
embodiment of the invention, including an application component. 

Figure 2 is block diagram illustration an example of system connections using the 
fiamework of the preferred embodiment. 

Figure 3 is an interface digram for the client view of the framework of Figure 1. 

Figure 4 is a block diagram showing the architecture of the framework of the preferred 
embodiment including a fat application. 
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Figure 5 is an interface diagram for the infrastructure view of the framework of Figure 

1 . 



Figure 6 is a block diagram showing the architecture of the framework of the preferred 
embodiment, including the runtime context. 



5 



In the drawings, the preferred embodiment of the invention is illustrated by way of example. It is 
to be expressly understood that the description and drawings are only for the purpose of illustration 
and as an aid to understanding, and are not intended as a definition of the limits of the invention. 



10 detai led description of the preferred embodiment 

Referring to Figure 1 , there is illustrated in a block diagram the architecture of the framewoilc of the 
preferred embodiment. 

The term "fiamework" relatesto object oriented programming languages and systems. The preferred 
embodiment is described below with reference to the object oriented language Java. Terminology 
15 relating to the Java language is used in the description of the preferred embodiment. It will be 
appreciated by those skilled in the art that the use of object oriented languages such as Java 
facilitates the description of the preferred embodiment. However the protocols of the preferred 
embodiment can be adopted and adapted to in other programming environments. S imi larly, the 
preferred embodiment can be implemented without using frameworks, although there are advantages 
20 to both implementing and describing the preferred embodiment using the notion of frameworks. 

"Frameworks" are used in this application to mean a collection of classes or interfaces in an object 
oriented programming language which is designed to guide and constrain how a communication or 
function is to be carried out by a system making use of the framework. A framework is similar in 

6 
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certain respects to libraries. However, a library is typically a collection of routines or data 
definitions which must be subject to relatively extensive prog ramming and data design steps before 
the subroutines and/or data definitions of the library are usable. In contrast, a framework not only 
defines data structures and methods but also provides a defined interrelationship which ensures that 
5 the methods and data structures are usable with limited input from the user. 

The user of a framework is able to use certain of the objects defined in the framework and is able, 
where permitted by the framework design, to extend certain of the objects defined in the fiamework. 
Thus a framework both provides predefined functionality and data and permits the extension of such 
predefined functions and data by the user of the framework. A framework therefore enables and 
1 0 constrains the user with respect to accessing resources and communicating in computer systems. 

By using frameworks, which are capable of tightly defining data, functionality, and interfaces, it is 
possible to utilize automated code generation facilities to write code to make use of the framework. 
In contrast, typical middleware solutions to communication between client and backend systems 
present substantial difficulties in automating the generation of code for use with the APIs of the 
1 5 potentially dissimilar middleware systems. 

The fiamework of the preferred embodiment is described in the Java language, but is capable of 
being implemented in other object oriented languages. 

Figure 1 presents a Common Connector Framework (CCF), in block 1 0. Associated with the CCF 
are two sets of interfaces. One is named the CCF Client View (shown as block 12) and is between 
20 the client or application component (shown as block 14) and the connector of block 1 0. The second 

interface is the CCF Infrastructure View (shown as block 16) which is between the coimector of 
block 1 2 and the environment specific infrastructure (shown as block 18). The environment that the 
CCF is running in as shown in Figure 1 is a well-defined component-based infrastructure. 

The term "interface" as used in this description refers to Java interfaces. Java interfaces are 
25 analogous to other object oriented language constructs referred to as protocols. An interface may 

7 
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be thought of as a class which defines an agreed-upon behaviour. A Java interface includes 
definitions of methods (and thus defines what behaviour of a class that implements the interface) but 
the definitions are null definitions. It is the class that implements the interface which must 
implement all the methods defined in the interface, thereby "agreeing" to certain behaviour. A class 
5 is able to implement more than one interface (for this reason, it is possible to view interfaces as 
supporting multiple inheritance). 

Returning to Figure 1 , the division of the CCF into the two separate interfaces of blocks 1 2 and 1 6 
allows for flexibility of implementation and use. The architecture of the framework of the preferred 
embodiment is designed to permit various clients (or application components) to use well-defined 
1 0 and consistent interfaces to create the connection with the desired backend systems. By dividing the 

CCF connector interfaces into a client view interface and an infiastructure interface, the client can 
be isolated from the details of how a particular infrastructure handles such functions as error 
handling, and trace logging (RAS services), or security controls. 

The framework of the preferred embodiment permits all clients using the framework to utili 2 e the 
15 same interface definition to obtain access to all backend systems. The CCF connector will be 
different for each specific backend system but the defined client and infiastructure interfaces permit 
each CCF connector to provide a well-defined structure for communication between the client and 
the backend system. As is set out below, the interfaces defined in the preferred embodiment are 
sufficiently simple to provide ease of use, yet are sufficiently powerful to be useable by all manner 
20 of client and backend system combinations. 

The set of interfaces shown in Figure 1 constitutes a contract between the client block 14, the 
connector block 1 0 and the platform specific infiastructure block 18. The set of interfaces is small 
enough to allow straightforward implementation, yet flexible enough to acconunodate different 
requirements of components. As will be seen from the following description, a client that uses 
25 different connectors does not need to interface with numerous APIs of different middleware systems. 

Instead, the client is able to use the same interface calls to the connector to establish a connection, 

8 
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execute requests and disconnect from the backend system, with the differences between connectors 
being limited to two well defined interfaces. 

The architecture shown in Figure 1 also permits the connector implementation to be independent of 
the platform it runs on (the infrastructure 1 8 in Figure 1), since it can request services, such as error 
5 reporting, security information or coordination, from the infrastructure by using well defined set of 
interfaces. Similarly, infrastructure 1 8 does not need to be concerned with the details of any 
particular connector implementation and can implement generic services such as connection 
management and coordination that can be used by any CCF connector. 

A CCF connector is a package of classes which include implementations of the interfaces in the CCF 
1 0 (those interfaces indicated as being implemented by the connector in Figures 3 and 5, below). The 
classes in the package of a particular CCF connector are written to permit communication with a 
particular backend system. 

Figure 2 is a block diagram which illustrates how different clients are able to use imp li»nrigmtaiiif» n s 
of CCF connectors to establish communication with backend systems. In the ^cample of Figure 2, 
1 5 there are two different infrastructures, shown as infrastructure n in block 20 and infi:astructure p in 

block 22. Clients are shown as Client 1 , Client2, Client3, and Client4 in blocks 24, 26, 28, and 30, 
respectively. Clientl and Client2 run in infrastructure n, while Clients and Client4 run in 
infrastructure p. The two backend systems are illustrated as BackendA and BackendB, in blocks 32 
and 34, respectively. 

20 The CCF connector implementations to permit the clients of blocks 24 to 30 to communicate with 

the backend systems of blocks 32 and 34 are shown as blocks 40, 42, 44 and 46. Block 40 represents 
a CCF connector implementation which is written for BackendA. This package contains classes 
which include implementations of interfaces ConnectionSpec, InteractionSpec, Communication, 
Managed Factory, Managed, Resource, and an extension of the class Logonlnfoltems. These 
25 interfaces and this class are described below. 



9 




CA 02248634 1998-09-24 



CA9-98-028 

Connector implementation 40 has available to it the infiastructure services of infiastnicture n. This 
is accomplished by use of the Infrastructure View interface, as implemented for infrastructure n. The 
Infrastructure View interface is described in more detail below. 

Similarly, Clients uses CCF connector implementation 44 for BackendA, which also makes use of 
5 the Infrastructure View interface to obtain the infrastructure services of infiastructure p (block 22). 

In a like manner, Client2 and Client4 make use of CCF connector implementations designed for 
BackendB, which connector implementations run in infrastructures n and p, respectively. Client2 
also makes use of the CCF connector implementation for BackendA. In this case Client2 must 
create a separate communication with Connector A n. 

10 As can be appreciated, the clients of the example of Figure 2 will make use of the common interface 

provided in the CCF Client View interface to carry out the communication with the two backend 
systems. The CCF connector implementations for the two backend systems wiU likewise make use 
of the common interface provided in the CCF Infrastructure View interface to obtain access to the 
necessary services of the infi-astructures. 

15 As referred to above, the framework of the preferred embodiment includes interfaces which 
themselves define methods. The following describes the interfaces in the framework of the preferred 
embodiment, mcluding which components implement and which components use the interfaces, and 
which methods are defined in the interfaces. 

Figure 3 is an interface view which describes the interfaces of the Client View of the Common 
20 Connector Framework. The Client View represents the contract between the thin client or 
^plication component and the connector implementation. The following interfaces define the 
connector to the client; 

1 . Commtmication (block 50 in Figure 3) is an interface implemented by all CCF connectors. 
This interface defines methods to establish connection with the target system, perform the 
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communication and terminate the communication. The interface defines the following 
methods (set out in block 52): 

_ public abstract void connect() 

This method establishes the connection with the backend system and if necessary can 
5 also perform any communication specific setup such as verification of the validity 

of the client’s security credentials. 

_ public abstract void execute (InteractionSpec interactionspec. Object input. Object 
output) 

This method performs one interaction with the backend system. The input and 
1 0 output objects depend on the backend resource used. 

_ public abstract void disconnect 0 

This method terminates the communication with the back end system and 
performs the necessary cleanup preparing the communication for the next use. 



1 5 2. ConnectionSpec (block 54) is an interface encapsulating all the cotmection relevant 

properties such as host name, port number or the queue name. The ConnectionSpec is 
able to create the communications and provide a unique identifier, such as hash code, for 
each connection. This interface defines two methods (in block 56): 

_ public abstract Communication createcommunication() 

20 This method creates a new communicaton. 

_ public abstract int hashcode() 

This method calculates and returns a coimection specific unique identifier based 
on the connection properties (for example, host name, queue name). 
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3. InteractionSpec (block 58) is an interface which defines request specific properties 
such as program or transaction name, the interaction mode defining whether the request is 
synchronous or asynchronous (SEND-RECEIVE, SEND, RECEIVE), and other 
connector specific properties. 

5 As Figure 3 indicates, the CCF connector implements the interfaces of the CCF Client View, and 
the client uses the interfaces. The methods set out in the interfaces of the CCF Client View are 
sufficiently generalized and powerful to permit the Client to access the backend system which a 
particular connector is defined to connect to. As will also be appreciated, the client noting the 
connector of the CCF does not have to deal with those infiastructure functions such as RAS services, 
10 which may be dealt with by the CCF connector in the Infiastructure View. Thus error handling 
functions, for example, which are expressly dealt with by clients using the typical middleware 
product, are no longer necessarily handled at the client level. 

However, in some cases the client is designed so that the client itself uses the infiastructure services 
which are set out in the Infiastructure View interface. Figure 4 presents a view of the CCF by such 
15 a fat application client. In Figure 4 CCF Connector implementation 70 is shown having CCF Client 

View 72 and CCF Infrastructure View 74. There is no infiastructure shown as a separate block in 
the block diagram of Figure 4. Instead, Fat Application 76 is shown. This type of more complex 
client uses the infiastructure interface of CCF Infrastructure View 74 for a direct access to the 
services such as coordination or security. As will be appreciated, the architecture of Figure 4 is a 
20 special case of the Figure 1 architecture of the preferred embodiment. The description below will 
focus on the Figure 1 architecture, but the preferred embodiment may be implemented with 
necessary modifications to provide the architectme of Figure 4. 

An example of how the interfaces defined above may by implemented in classes which are used by 
a client may be seen in reference to the example set out in Figure 2. Clientl in Figure 2 makes use 
25 of ConnectorA_n. ConnectorA n is a package which contains classes which implement interfaces 
as defined above. In this example, assume that ConnectorA_n implements the ConnectionSpec 
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interface by class A_nConnectionSpec, InteiactionSpec by class A_nInteractionSpec, and 
Communication by class A_nCommunication. 

The client may then create a new object using the following code: 

Clientl_ConnectionSpec = new ConnectorA_n.A_nConnectionSpec 

5 The object Client l_ConnectionSpec is an instance of the ConnectionSpec interface implementing 
class A_nConnectionSpec, as found in the package ConnectorA_n. 

A communication object may then be created by the client by using the CreateCommunication 
method which is found in the A_nConnectionSpec class (mandated by the ConnectionSpec 
interface): 

10 A^Conimunication c = cilentl_ConnectionSpec.CreateCc3inmunicatlon O 

An interaction specification must also be created by the client. The following code creates the object 
ClientlJnteractionSpec: 

A_plnteractionSpec ClientUnteractionSpec » 

new ConnectorA_n-A.nInteractionSpec 

15 The client may then define the properties of the Clientl_InteractionSpec object to reflect what 
interaction is desired with the backend system. The description of the ConnectorA_n package will 
also indicate what object definition is required for input and output to and from the backend system. 
The client uses c . connect ( ) to create a connection. The client may then use the execute method, 
as defined in the class A nCommunication which implements the Communication interface in 
20 package ConnectorA n. For example: 

CAUj c. execute {A_nInteractionSpec Clientl_InteractionSpec, 

InputObject input, OutputObject output) 

The above example illustrates, the manner in wdtich the interfaces of the CCF Client View are used 
to permit a client to communicate with a backend system. In the example, the call to the c.execute 
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method ensures that the interaction desired by the client will be carried out on the input in a manner 
as defined in the interaction specification and that the output will receive the result of that 
interaction. 

In Figure 5, the Common Connector Framework Infrastructure View is illustrated. As described 
5 above, the CCF Infrastructiue View represents the contract between the implementation of a CCF 
connector and a platform specific infiastructure. The interface between the CCF connector and the 
infiastructure differs fiom the contract between the thin client and the connector. In the latter, the 
connector implements and the client uses the set of interfaces (defined in the Client View interface 
shown in Figure 3). In the case of the relationship between the CCF connector and the infrastructure, 
1 0 both the connector and the infiastructure have to implement the set of interfaces to be used by the 

other. 

The interfaces set out in the CCF Infiastructure View are shown in Figure 5. The interfaces (and 
the class) which are implemented by the CCF connector and used by the CCF infrastructure are the 
ManagedFactory interface 80, Managed interface 82, Resource interface 84, and Logoninfoltems 
1 5 class 86. The interfeces which are implemented by the infiastructure and used by the CCF connector 

are CormectionManager 88, Coordinator interface 90, Identifier interface 92, Logoninfor interface 
94, and RASService interface 96. The implementations of the interfaces of CCF Infrastructure View 
are designed to interact with the implementations of interfaces which are foimd in the CCF Client 
View (as shown in Figure 3). 

20 The interfaces (and class) of the CCF Infiastructure View which are implemented by a CCF 
coimector are designed as follows: 

1 . ManagedFactory interface 80 provides a cormection manager (an implementation of 
ConnectionManager interface 82) with the generic way of creating cormections fiom 
ConnectionSpec 54. The ManagedFactory interface 80 defines the following method: 

25 - public Managed createManaged (ConnectionSpec connectionspec) 
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This method creates a managed connection based on the connection specification (from the 
CCF Client View ConnectionSpec 54). 

2. Managed interface 82 is implemented by a managed connection. A connection manager 
(implementation of ConnectionManager interface 88) is able to control the entire life cycle 

5 of the managed connection fi?om its creation by an implementation of ManagedFactory 

interface 80 to its destruction using the destroyManaged method which is defined in 
Managed interface 82. Managed connections can also be reused by the connection manager 
and therefore methods are included which relate to the reuse of a managed connection. The 
main methods of Managed interface 82 are: 

10 - public void destroyManaged 0 

This method allows a connection manager to destroy a managed connection. The method is 
used, for example, in cases where the connection manager reduces the number of the 
connections managed by it. 

- public void prepareManagedForReuse () 

1 5 This method prepares the connection to be reused by the connection manager. 

3 . Resoiuce interface 84 defines the coordinator view of the connection resource. It contains 
resource definition similar to that found in JTS/OTS and includes one and two phase commit 
protocol st^iporL Resource interface 84 defines the following methods: 

- public void commit () 

20 The coordinator tells the resource that its state is valid and it is no longer needed. 

- public void rollback() 

The coordinator tells the resource that its state is invalid and it is no longer needed. 

- public void commitOnePhase 0 

The coordinator teUs the resource that it can commit work using a one phase commit 
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protocol. 

- public int prepare () 

The coordinator asks the resource whether its state is valid and if a subsequent call to conunit 
would succeed. 

5 In addition to the interfeces defined as described above, the connector extends and uses the following 

class which is in the CCF Infrastructure View; 

4. Logonlnfoltems class 86 is the superclass for all connector specific Logoninfoltem 
classes. It defines the way in which a given CCF connector accesses security items specific 
to that connector. 

10 _ public logoninfo getlogoninfo 0 

This method returns the logoninfo object used to carry out the logoninfoitems 
access methods. The methods are used in this object. 

_ public string getpassword 0 

This method returns the password. 

15 _ public string getuser 0 

This method returns the user. 

_ public void setpassword (string password) 

This method sets the password. 

_ public void setuser (string user) 

20 This method sets the user. 



As the above description indicates, the CCF Infrastructure view contains interfaces (and one 
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superclass) which require that a protocol for managed connections be created when the 
framework of the CCF is instantiated. When a client wishes to access a backend system, the 
client will call instances of objects created in classes which implement the interfaces of the CCF 
Client View. The CCF connector implements the interfaces in the CCF Infrastructure View to 
permit a managed connection to be created with the backend system. The managed connection 
makes use of infiastructure services which are made available to the CCF connector object in 
accordance with the interfaces in the CCF Infrastructure View which are implemented by each 
particular infrastructure which supports the Common Connector Framework. 



10 Refening again to Figure 5, the interfaces of the CCF Infrastructure View which are 
implemented by the infrastructure are designed as follows: 

1. ConnectionManager interface 88 defines the common connection manager as seen by a 
CCF connector. ConnectionManager interface 88 defines management of connections 
based on the hashcode method of ConnectionSpec interface 54. If the infrastructure 
1 5 provides session ID then the connection manager implementing the ConnectionManager 

interface 88 will manage the connection based on SessionlD (see below description of the 
Identifier interface), as well. The connection manager uses the connection management 
properties, defined on the ConnectionSpec to create, reuse and destroy connections. 
ConnectionManager 88 relates to connection management fimctions which can include 
20 timeout requirements, billing constraints, or maximum simultaneous connections, for 

example. 

ConnectionManager interface 88 defines the following methods: 

- public Managed reserve (ManagedFactory managedfactoryi ConnectionSpec 
25 connectionspec) 
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This method reserves a connection for the caller and returns it for the exclusive use of the 
caller. Typically this will be called in the connect method (shown in block 52 of Figure 3) 
of an implementation of Communication interface 50. 

- public void clearForSessionlD (Identifier aSessionID) 

5 This method clears the used connections list of the coordinator identified by the session. 

-public void release (Managed managed) 

This method is called to release a connection used exclusively by a client Typically this 
will be called by the disconnect method in the implementation of Communication 
interface 50. 

10 2. Coordinator 90 defines the common coordinator interface as seen by an 

implementation of the Resource interface of a coimector. Coordinator 90 allows 
registration of resources. Since some resources should be handled before or after the 
connection resources, the appropriate registration method should be used for such 
resources (registerBefore or registerAfter). An implementation of the Coordinator 
1 5 interface also returns a unique identifier, defined as a CoordinationlD object, that may be 

used by a backend system which is defined to require such an ID. Coordinator interface 
90 is related to coordination of logical units of work and provides a functionality to 
permit certain resources to be logically grouped such that interactions are appropriately 
handled to preserve the logical interrelationship of the resources. 

20 Coordinator interface 90 defines the following methods: 

- public void clearAllRegistered 0 

This method disposes of all the resources registered vwth the coordinator. 

- public Identifier getCoordinationID 0 

This method returns the unique Coordination Idendfier of this coordinator. The 
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CoordinationlD is not changed by commit or rollback methods. 

- public void register(ResouTce resource) 

This method registers the Resource with the coordinator. 

- public void registerAfter(Resource resource) 

5 This method registers a resource (not a connection) to be registered after the registered 

connections are registered. 

- public void registerBefore(Resovirce resource) 

This method registers a resource (not a connection) to be registered before the registered 
connections are registered. 

10 3 . Identifier interface 92 is a generic interface implemented by objects that need to 

provide a unique identifier. In the framework of the preferred embodiment, such a unique 
identifier is used for the SessionlD (used by the connection manager to organize the 
connections) and is used for the CoordinationlD by the coordinator. 

4. Logoninfo interfece 94 defines the common way in which the infrastructure accesses 
1 5 the security items and provides support for security requirements on the connector and 

infrastructure side such as: on demand fetching of values, preloading of values, connector 
having an environment independent way of getting logon info and type constraints for 
properties. These requirements are realized by two elements in the framework of the 
preferred embodiment: the Logoninfo interface and the Logoninofltems class. 

20 



The inqiiementations of the Logoninfo interface represent an infrastructure specific way 
of accessing security data. The Logoninfoltems class and its connector specific 
subclasses define which specific security items a connector is looking for. The 
Logoninfoltems class is to be extended by the connector by the definition of subclasses 
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which are specific to the security of the backend system which the connector is designed 
to provide a connection with. 

The lookup in the infiastructure is implemented using the Logoninfo object passed on 
construction (as is described below, a connector retrieves the Logoninfo to use from the 
5 runtime context). Even when no further items besides user and password are needed by a 

particular connector, the connector has to introduce a subclass, so that a Logoninfo 
implementation can differentiate Logoninfoltems on a connector basis. 

The Logoninfo interface defines the following methods: 

- public Object getitem (Logoninfoltems logoninfoltems. String itemname) 

10 This method retrieves a named item from the Logoninfo object. 

- public void setitem (Logoninfoltems logoninfoltems. String itemname. Object item) 
This method sets a named item from the Logoninfo object. 

5. RASService interfece 96 defines the common reliability, availability and serviceability 
services to all connectors. It allows error and trace logging by providing the log methods 
1 5 and the mechanism to retrieve the log and error streams. 

The above description indicates how the CCF defines the protocols for managed connections, 
coordinated resources, logon information and RAS services. For a particular connector, the 
infiastructure must implement the interfaces ConnectionManagcr, Coordinator, Identifier, Logoninfo 
and RASService. An infiastructure which has implemented these interfaces can be used by any 
20 connector which in turn implements the interfaces of the CCF Infiastructure View, namely 
ManagedFactory, Managed, Resource and the class Logoninfoltems. Thus an infiastructure which 
implements the interfaces set out above supports all CCF connectors. The CCF Infiastructure View, 
as implemented on the CCF connector side, will vary for different backend systems. The 
implementation of the inter&ces ManagedFactory, Managed, Resource and the class Logoninfoltems 
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will vary based on the details of the backend system to be connected to. However, once written, the 
connector for a particular backend will be available to be used in any CCF-supporting 
infrastructures. 

The CCF Infrastructure View design ensures that managed connections made by a client using a 
5 CCF connector are run through a connection manager in the infrastructure and that resources are 
coordinated by the infrastructure. The connector itself ensures that the logon information is passed 
to the infrastructure by way of the accessor methods which use the Logoninfo intnfare 

According to the preferred embodiment, the infrastructure services are made available to a connector 
implementation by use of the RuntimeContext. This is a class which defines all the infrastructure 
10 services as used by the connector as shown on Figure 6. 

To support CCF connectors, an infrastructure must extend the RuntimeContext class. In simple 
cases, the CCF itself may extend the default RuntimeContext to create a subclass which may be 
sufficient to for a particular infrastructure. In other cases, a subclass which is specific to the 
infiastruettire is created. A RimtimeContextis then set up at runtime. A connector implementation 
1 5 then uses the RuntimeContext to obtain the infrastructure services. 

The RimtimeContext defines the following methods: 

- public static RuntimeContext getcurrent 0 

This method returns the runtime context associated with the current thread. If there is none 
it creates a default runtime context, associates it with the thread, and returns it to the caller. 

20 - public void setCurrent (RimtimeContext runtimecontext) 

This method associates a runtime context with the current thread. 

- public ConnectionManager getConnectionManager Q 

This method returns the Connection Manager of this RimtimeContext. 
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- public Coordinator getcoordinator 0 

This method returns the Coordinator of this RuntimeContext. 

- public Logoninfo getLogonInfo () 

This method returns the class containing the security information of the RuntimeContext. 

5 - public RASService getRASService 0 

This method returns the RASService of this runtime context. 

_ public Identifier getSessionID () 

This method returns the unique session identifier associated with this runtime 
context. 

10 

_ Public void close 0 

This method does the final clean up at the end of a session to handle resource and 
managed connections which remain in use. It also removes the RuntimeContext 
of the current thread. 

15 The RuntimeContext class is used to permit the infrastructure to create a runtimecontext 

which is associated with the thread that the application component is running in. This thread 
is also the thread on which an instance of a CCF coimector is called on. This mechanism of 
associating a runtimecontext with the thread of the connector gives the connector access to 
the infirastructure services at runtime. 

20 Returning to Figure 2, the above description indicates how the definitions of the protocols 

between the client, connector, and interface, as set out by the Java language interface 
construct, permits coimectors to be built which can easily run in different infiustructures and 
which provide a standard for different clients to access backend systems in a uniform way. 
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Although a preferred embodiment of the present invention has been described here in detail, 
it will be appreciated by those skilled in the art, that variations may be made thereto, without 
departing from the spirit of the invention or the scope of the qipended claims. 




CA 02248634 1998-09-24 



CA9-98-028 

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY OR 
PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS: 

1 . An object oriented framework for communication between an application component 

running in an infrastructure and a backend system, comprising 

a connector protocol definition for a implementation by a connector component for 
communication between the {qjplication component and the backend system, 

the framework further comprising 



a client view protocol definition for communication between the application 
component and the connector component, and 

an infrastructure view protocol definition for communication between the 
infrastructure and the connector con^onent. 

2. The object oriented framework of claim 1 in which the client view protocol definition 
comprises 

a connection speciGcation protocol definition to define commimication of backend system 
connection properties to the connector component, 



an interaction specification protocol definition to define communication of properties associated 
with application component requests of backend system, 

a communication specification protocol definition to define connection, disconnection 
and execution of communication functions for commimication between the application 
component and the backend system. 
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3 . The object oriented framework of claims 1 or 2 in vdiich the infrastructure view 

protocol definition comprises 

a set of managed connection protocol definitions to define the creation and management of 
connections between the application component and the backend system, wherein the set of 
managed connection protocol definitions comprises a first subset of managed connection 
protocol defimtions for implementation in the connector component and a second subset of 
managed connection protocol definitions for implementation in the infiastnicture, 

a set of resource coordination protocol definitions to define coordination of resources relating 
to connections between the application component and the backend system, wherein the set 
of resource coordination protocol definitions comprises a first subset of resource coordination 
protocol definitions for implementation in the connector component and a second subset of 
resource coordination protocol definitions for implementation in the infrastructure, 

an identifier protocol definition for implementation by the infrastructure to provide connector 
component access to a unique identifier, 

a logon Information protocol definition for implementation by the infrastructure to provide 
connector component access to security items in the infiastnicture, 

a component definition for logon information for definition of security items required for 
connector component communication between the application component and the backend 
system, 

a RAS protocol definition for implementation by the infrastructure to provide connector 
access to error and trace logging. 

4. The object oriented framework of claim 3 wherein the application component runs on a 
thread in an infrastructure providing infrastructure services, the object oriented framework 
further comprising 

means for the infrastructure to provide infrastructure services to the connector component by 



25 




CA 02248634 1998-09-24 

CA9-98-028 

associating a runtime context of the infrastructure services with the thread of the application 
component 

5. The object oriented fiamework of claim 3 in which 

the first subset of managed connection protocol definitions comprises 

a protocol defimtion for the creation of a connection, and a protocol definition for 
providmg a connection manager component with control over a managed connection, 

and m which the second subset of managed connection protocol definitions comprises 
a protocol definition for reserving and releasing managed connections. 

6. The object oriented frameworic of claim 3 in which 



a protocol definition for creating a view of a connection resource for use by a resource 
coordinator. 



and m which the second subset of resource coordination protocol definitions comprises 
a protocol definition for registration of resources by a resource coordinator. 

7. The object oriented fiamework of claims 1, 2 or 3 in which the fiamework is implemented in 
the Java programming languages and in which the protocol definitions are interfaces in the 
Java programming language. 

8. The object oriented framework of claim 7 in which the application component runs on a 
thread in a Java infrastructure, the object oriented framework further comprising means for 
the infrastructure to provide infiastructure services to the connector component by 
associating a Java runtime context with the thread of the application component 
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9. A computer system comprising a set of tools for use to create a communication between a 
first computer system component and a second computer system component, the tools 
constraining the communication to occur using a predefined protocol, the set of tools 
comprising 

a connector tool for a implementation by a connector for communication between the first 
computer system component and the second computer system component, the connector 
tool comprising 

a client view tool for defining communication between the application component and 
the connector component, and 

an infrastructure view tool for defining communication between the infrastructure and 
the connector component 
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Single threaded context. Le. the thread the connector 
is called on is the same on which the infrastructure 
established the RunthneContext 
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